Re: GSS API (as a DLL)...

To: chuckie@panix.com, www-security-owner@ns1.rutgers.edu
Subject: Re: GSS API (as a DLL)...
From: Paul Leach <paulle@microsoft.com>
Date: Thu, 18 Aug 94 15:14:10 TZ
Cc: www-security@ns1.rutgers.edu

----------
| From: Ramin Firoozye  <rpa@netcom.com>
| To: Alec H. Peterson  <chuckie@panix.com>
| Cc:  <www-security@ns1.rutgers.edu>
| Subject: Re: GSS API (as a DLL)...
| Date: Thursday, August 18, 1994 1:16PM
||
| One obvious option is to avoid the
| Windows DLL behavior of looking for a library along a series of paths.
| Windows currently looks in the current application directory, the windows
| directory, or any other indicated path.

If you specify a full path name to the Windows "LoadLibrary" call 
(which is the one that loads DLLs)  then it won't follow any search 
path.  This form is what I would use in a security sensitive program 
that wanted to load a DLL.

|
| Here's what I would argue is what would work: make sure plug-ins are
| loaded from absolute paths. Make sure, at the point of loading, that the
| DLL file is NOT writable (some Unixes that memory map files and use the file
| for implementing statics and globals might object), and finally, calculate
| a CRC (or an MD5 signature) of the file and compare it against a stored
| read-only file of checksums. This should at least establish location
| and content. Now there are ways of spoofing even these, but at least
| the window has been considerably narrowed. This level of checking should
| be implemented for every shareable library access upon initial loading. Once
| loaded, it's fairly safe to assume you can continue on and invoke the
| functions within...

I agree with the above, and wanted to make sure that folks knew it'll 
work on Windows, too.

Paul